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EXECUTIVE  SUMMARY 

Part  of  our  College  mission  is  distribution  of  the 
students’  problem  solving  products  to  DoD 
sponsors  and  other  interested  agencies  to 
enhance  insight  into  contemporary,  defense 
related  issues.  While  the  College  has  accepted  this 
product  as  meeting  academic  requirements  for 
graduation,  the  views  and  opinions  expressed  or 
implied  are  solely  those  of  the  author  and  should 
not  be  construed  as  carrying  official  sanction. 
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I.  Purpose-.  To  inform  mission  ready,  tactical  aircreus  about 
the  operational  flight  program  (OFP)  update  cycle. 

II  .  Problem :  As  an  AN/ARN-101  and  AN/AVQ-EB  CPave  Tack) 
technical  focal  point  at  USAFTAWC,  the  author  found,  TAF  wide,  a 
general  lack  of  user  awareness  of  the  OFP  update  cycle.  The  OFP 
update  cycle  is  designed  to  allow  users  to  suggest  and  recommend 
changes  to  software  controlling  embedded  avionic  computers, 
commonly  known  as  OFPs .  Changes  to  software  may  be  generated  in 
a  number  of  ways.  A  change  in  the  operational  mission, 
equipment,  threat,  or  tactics  may  require  a  corresponding  change 
to  embedded  avionic  computer  software.  The  system  to  effect 
user’s  change  requirements  exists,  however;  a  lack  of  awareness 
and  involvement  prevents  cycle  employment  to  its  maximum 
potential  . 

III.  Data :  The  procedures  for  changing  operational  software 
involve  coordination  through  as  many  as  four  major  commands.  The 
procedures  are  "buried"  in  multiple  layers  of  regulations  and 
manuals.  Consequently,  the  operational  aircrew  may  not  be  aware 
of  the  cycle.  This  lack  of  awareness  could  actually  be 
decreasing  the  operational  effectiveness  and  suitability  of 
embedded  avionic  computer  software  in  today’s  tactical  fighter 
aircraft.  The  manuscript  is  targeted  towards  the  operational, 
mission  ready  aircrew.  Herein,  the  operational  aircrew  is  shown 
haw  he  fits  into  the  system  and  can  become  an  active  participant. 
The  article  describes  avionic  computer  proliferation  within  the 


TAF .  The  description  provides  the  reader  an  appreciation  for  the 
nature  and  breadth  of  the  problem.  The  author  explains  a  Few 
terms,  uncommon  to  the  operational  aircrew,  for  two  reasons. 
First,  the  terms  provide  a  basic  understanding  of  the  cycle  so 
the  reader  understands  the  cycle  in  the  terms  of  the  cycle 
software  engineers.  Secondly,  they  serve  to  educate  the  reader 
in  hopes  that  armed  with  some  of  the  terms  unique  to  the  system, 
he  can  better  communicate  with  those  involved  with  the  system  by 
speaking  their  language.  The  article  then  describes  the  update 
cycle  in  preparation  for  the  aircrew  to  become  involved  in  the 
process.  Next,  the  bottlenecks  to  the  system  are  explained.  The 
reader,  by  circumventing  these  bottlenecks,  can  perhaps  expedite 
his  recommendation  through  the  cycle.  The  article  ends  with  some 
recommendations  and  suggestions  for  improvement. 

V.  Recommendations :  An  increase  in  user  awareness  and 
involvement  in  the  operational  flight  program  update  cycle  can 
increase  operational  effectiveness  and  suitability  of  avionic 
computer  software  in  today’s  tactical  fighter  aircraft.  This 
manuscript  describes  the  complexities  involved  in  the  OFP  update 
process  and  gives  the  operational  tactical  aircrew  the  knowledge 
and  the  motivation  to  become  involved  in  the  process.  Therefore, 
recommend  that  the  manuscript  be  published  in  USAF  Fighter 
Weapons  Review  to  provide  maximum  target  audience  exposure. 
Potentially,  the  result  could  be  a  low-cost  increase  in 
operational  effectiveness  and  suitability  of  today’s  tactical 
fighter  aircraft. 
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THE  OFP  UPDATE  CYCLE  NEEDS  YOU! 

INTRODUCTION 

What  have  you  done  far  your  OFP  lately?  If  your  answer 
resembles  something  like  "What  are  you  talking  about?" —  then  you 
are  right  in  line  with  the  findings  of  a  1S85  study  commissioned 
to  determine  the  magnitude  of  problems  associated  with  the 
software  explosion  occurring  within  advanced  avionic  subsystems 
in  the  Air  Force  C5:29).  In  general,  the  study  found  that  "there 
were  significant  opportunities  to  improve  operational  readiness 
by  increasing  the  management  attention  applied  to  solving 
software  development  and  support  problems"  C5:29).  The  obvious 
question  now  becomes —  Why  should  I  care?  Where  do  I  fit  in  the 
loop? 

As  a  mission  ready  operational  aircrew,  at  your  fingertips 
lies  the  opportunity  to  improve  your  operational  combat 
capability,  increase  mission  efficiency,  and  perhaps  save  your 
skin  someday.  Through  the  Operational  Flight  Program  CQFP) 
update  cycle  you,  as  a  user,  have  a  vote  in  the  improvement  of 
the  software  which  controls  your  on-board  digital  avionic  sub¬ 
systems  C 13: 2-3).  You  don’t  have  to  be  a  computer  expert,  or 
possess  magical,  mystical  knowledge  of  internal  computer 
workings.  You  only  need  the  desire  to  improve  the  operational 
capability  of  your  equipment  so  you  can  do  your  job  better.  The 


□FP  update  cycle  needs  your  expertise  as  a  combat  aviator--  with 
the  day-to-day  experience  of  employing  a  weapons  system--  to 
improve  the  combat  effectiveness  of  your  digital  avionic  computer 
software--  OFPs . 

To  introduce  the  DFP  update  cycle  requires  some  preliminary 
information.  We’ll  start  with  a  description  emphasizing  the 
problem’s  magnitude.  It’s  bigger  than  you  think.  An  explanation 
of  terms  unique  to  the  system  will  help  you  understand  the  OFP 
update  cycle.  A  short  word  picture  of  the  update  cycle  will  show 
where  you  fit  in  the  system.  Finally,  by  looking  at  some 
bottlenecks  in  the  system,  you’ll  see  how  you  can  provide  some 
valuable  assistance  to  the  folks  who  maintain  your  OFPs. 


Section  Two 


AVIONIC  SOFTWARE  PROLIFERATION 

Recent  advances  in  computer  technology  have  resulted  in  a 
proliferation  of  embedded  digital  avionic  computers  and  software 
in  today’s  tactical  fighters.  "In  the  tactical  arena,  the 
advanced  computerized  fire-control  systems  and  fly-by-wire 
digital  flight  controls  now  employed  on  the  F-16  fighter  would 
have  been  impossible  a  few  years  ago"  according  to  Donald  C. 
Latham,  Assistant  Secretary  of  Defense  for  Command  Control 
Communications  and  Intelligence  (2:65).  Current  avionic  sub¬ 
systems  such  as  radar  warning  receivers,  electronic  counter¬ 
measures  pods,  navigation  and  weapons  delivery  sets,  targeting 
pods  and  virtually  every  major  digital  avionic  sub-system 
introduced  recently  have  a  reprogrammable  computer  controlling 
their  functions  (7:21).  The  Advanced  Tactical  Fighter  (ATF) 
provides  an  excellent  example  of  digital  avionics  technology 
proliferation . 

The  ATF  is  being  designed  from  the  "ground  up  as  a  totally 
integrated  avionics  suite ...  using  the  Pave  Pillar  avionics 
integration  concept"  (6:52;  1:514-S1B).  According  to  General 
Lawrence  A.  Skantze,  retired  commander  of  Air  Force  Systems 
Command,  ATF  engineers  "will  integrate  the  functions  of 
communications,  navigation  and  identification  through  the  ICNIA 
(integrated  communications  navigation  identification  avionics) 


Csici  program  and  the  functions  of  electronic  warfare  through  the 
INEWS  C integrated  electronic  warfare  system)  CsicD  program" 
(6:52-53).  Secretary  Latham  estimates  that  "a  software 
architecture  embodying  an  estimated  7, lines  of  code  will 
be  needed  to  make  the  ATF's  avionics  system  work"  (2:65).  Hand- 
in-hand  with  embedded  digital  avionic  computer  proliferation  is 
the  proliferation  of  software  required  to  operate  these  new 
systems . 

In  his  article  "Project  Bald  Stroke:  A  Plan  to  Cap  A 
Software  Crisis",  Major  General  Monroe  T.  Smith,  DCS  Product 
Assurance  and  Acquisition  Logistics,  HQ,  AFSC  outlined  the  major 
problems  concerning  the  Air  Force  and  the  proliferation  of 
software  (5:30).  First,  "every  ten  years  there  is  an  order  of 
magnitude  increase  in  the  volume  of  software  on-board  Air  Force 
weapon  systems"  (5:30).  Second,  the  use  of  "integrated  circuits 
allows  more  functions  to  be  used...  increasing  the  software 
required  to  control  those  functions"  (5:30).  Third,  the  "demand 
for  software  will  increase  by  12^  a  year  for  the  next  two 
decades"  (5:30).  Finally,  General  Smith  finds  that  "70^  of  the 
cost  of  software  is  associated  with  the  support  of  the  software 
once  turned  over  to  the  operational  inventory"  (5:30).  What 
does  this  mean  to  the  user? 

It  means  software  is  here  for  the  duration,  controlling  now, 
more  than  ever,  the  functions  on  board  your  aircraft.  Sadly, 
there  hasn't  been  a  corresponding  increase  in  the  number  of 
software  engineers  to  support  the  software  proliferation  (5:23- 
30).  To  help  offset  the  imbalance,  the  article  provides  some 


observations  and  recommendations  to  help  control  the  "crisis." 

General  Smith  recommended  a  four  phase  plan  to  help  regain 
control  of  the  software  proliferation.  Preliminary  steps  are 
underway  to  provide  problem  awareness,  beginning  at  the  highest 
management  levels  (5:29).  The  second  phase  involves  education 
and  training.  Courses  at  the  Air  University  and  Air  Force 
Institute  of  Technology  now  include  "a  segment  on  software 
technology  and  management"  (5:29).  The  other  phases  involve 
planning  and  preparation  far  software  management  in  the  future 
(  5  :  29  )  . 

There  you  have  it.  There’s  a  lot  of  software  in  the  field, 
more  on  the  way  and  we  lag  in  keeping  pace  with  the 
proliferation.  But  you  can  help.  You,  the  everyday  user  can 
increase  the  operational  effectiveness  of  your  weapon  system  by 
becoming  involved  in  the  QFP  update  cycle.  You  are  the  systems 
experts —  you  use  them  everyday.  Once  you  learn  a  little  more 
about  the  system  that  supports  your  OFP,  you  can  participate  in 
the  cycle  and  see  to  it  that  you  have  the  absolute  best  software 
available  to  you  everytime  you  go  fly. 


Section  Three 


TERMS  EXPLAINED 

Before  an  effective  dialogue  can  occur  regarding  the  OFP 
update  cycle,  there  are  same  basic  terms  you  should  know.  CSee 
Table  1.)  They  are  the  common  language  of  the  software  update 
process  and  the  test  and  evaluation  business.  If  inspired  to 
became  an  active  participant  in  the  update  cycle,  your 
understanding  of  the  terms  will  be  of  great  benefit. 

An  operational  f light  program  (OFP)  is  the  computer  program 
required  to  operate  one  or  more  on-board  digital  avionic 
computers  (8:1).  Specific  aircraft  technical  orders  contain  the 
information  required  to  operate  the  system,  given  a  particular 
□FP .  Block  cucle  changes  occur  when  a  number  of  routine  changes 
are  assembled  and  processed.  Collectively,  the  changes  are 
termed  a  block  (8:33.  The  supporting  Air  Logistics  Center 
distributes  OFP  changes  as  Time  Compliance  Technical  Order  (TCTO) 
for  pasting  in  bath  the  aircrew  and  maintenance  technical  orders 
(7:49)  . 

Operational  effectiveness  and  suitability  refer  to  the 
usefulness  of  a  given  system  to  the  operator  and  the  system 
maintainer.  A  system  is  operationally  effective  if  it  provides 
the  operator  with  the  expected  response  when  called  upon  and  no 
unintended  responses  result.  A  system  is  operationally  suitable 
if  maintenance  on  the  system  meets  specific  standards  established 


DEFINITION 


OFP 


Operational  Flight  Program;  computer 
software . 


USER 


Customer,  OFP  user. 


BLOCK  CYCLE 


Collectively,  group  of  software  changes 
to  given  OFP. 


OPERATIONAL  Measure  of  system  usefulness  and 

EFFECTIVENESS  efficiency. 


OPERATIONAL  Measure  of  maintainability. 

SUITABILITY 


OT&E 


CSSP 


SCCSB 


Operational  Test  and  Evaluation;  Process 
mandated  at  all  DOD  levels  to  determine 
the  operational  effectiveness  and 
suitability  of  new  or  changed  systems. 

Computer  Software  Screening  Panel; 
working  group  consisting  of  managers, 
engineers  and  users.  Tasks  include 
reviewing  and  validating  candidate 
changes  to  OFPs . 

Software  Configuration  Control  Sub- 
Board;  Board  granted  authority  to 
approve  configuration  modifications  to 
OFP. 


TECHNICAL  FOCAL 
POINT 


VDD 


Individual  at  either  USAFTAUC  or 
USAFTFU1C  assigned  overall  management  of 
designated  sub-systems.  Serves  as  TAF 
system  expert.  Performs  liaison  between 
TAC,  users,  and  support  agencies. 

Version  Description  Document;  Single 
source  document,  distributed  with  each 
OFP  release.  Gives  current  change 
description  and  pending  changes.  Quick 
source  to  learn  OFP’s  "health." 


Table  1 .  Common  OFP  Cycle  Terminology . 
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for  the  system  C14:68). 

Updated  software  must  undergo  satisfactory  operational  test 

and  evaluation  COT&E)  prior  to  its  release  for  operational  use 

C 13 : 7 ) .  OT&E  policy  is  explicit  in  AFR  80-14  which  states: 

OT&E  is  the  field  test,  under  realistic  conditions,  of 
any  item  or  key  component  of  weapons,  equipment,  or 
munition  for  the  purpose  of  determining  the 
effectiveness  and  suitability  of  said  for  use  in  combat 
by  typical  military  users,  and  the  evaluation  of  the 
results  of  such  tests.  The  test  environment  will  be 
operationally  realistic  with  threats  representing 
hostile  Farces.  Typical  users  should  operate  and 
maintain  the  systems  under  conditions  simulating  combat 
stress  and  peacetime  conditions  C12:51). 

Headquarters  CHQ)  Tactical  Air  Command  CTAC)  typically 
conducts  QFP  tests  at  either  of  two  centers  established  for  test 
purposes  C9-.1-3).  The  Tactical  Fighter  Weapons  Center  CTFWC)  at 
Nellis  AFB ,  Nevada  is  responsible  for  TAC  assigned  OT&E,  although 
tactics  and  knowledge  of  our  adversaries  is  their  primary  mission 
C 1 1 :  1 )  .  The  USAF  Tactical  Air  Warfare  Center  CUSAFTAWC)  at  Eglin 
AFB,  Florida  is  primarily  responsible  for  TAC  assigned  OT&E  C10-.1- 
3)  . 

At  both  USAFTFWC  and  USAFTAWC,  TAC  has  established  Tactical 
Air  Forces  CTAF)  Technical  Focal  Paints  for  various  aircraft 
systems  CIO: 1-3;  11:1).  The  technical  focal  point  is  TAC’s 
working  representative  for  assigned  weapons  systems.  The  TAF 
technical  focal  point’s  duties  include  coordinating  all  matters 
concerning  a  particular  sub-system  to  include  software  maintenance 
CIO: 1-3;  11:1). 

The  Computer  Software  Screening  Panel  CCSSP)  is  a  working 
level  group  with  several  responsibilities  in  the  OFP  update  cycle 


(7 : 44) .  At  an  Air  Logistics  Center  CALC),  it  is  chaired  by 
either  the  item  manager  or  the  system  manager.  Its  membership 
includes  major  command  representatives,  users,  software 
engineers,  and  system  technical  experts.  Although  the  CSSP 
determines  the  feasibility  of  performing  software  changes,  it  has 
no  authority  to  perform  software  configuration  changes  (7:44). 

The  Software  Conf iguration  Control  Sub-Board  (SCCSB) 
consists  of  technical  personnel,  the  system  manager,  and  user 
representatives.  The  SCCSB  has  configuration  management 
authority  delegated  from  the  system  management  level  or 
Configuration  Control  Board.  The  SCCSB  authorizes  changes  to 
software  programs  and  their  release  and  distribution.  Changes 
are  coordinated  at  the  system  level  through  the  SCCSB  (7:45). 

The  supporting  ALC  prepares  a  Version  Description  Document 
(VDD)  for  every  software  block  cycle  change.  The  VDD  accompanies 
the  DFP  release  as  part  of  the  distribution  package.  It  is 
important  to  the  aircrew  because  it  describes  each  OFP  change  in 
the  black.  To  you,  the  VDD  serves  as  a  single  source  document 
for  studying  the  new  or  changed  OFP  capabilities.  In  addition, 
the  VDD  lists  the  status  of  impending  OFP  changes.  By  checking 
the  VDD  you  can  get  an  idea  of  the  OFP’s  "health"  and  review 
planned  OFP  changes  (17: — ;  IB: — ). 

While  this  is  in  no  way  an  all  inclusive  list  of  terms  used 
in  the  OFP  update  cycle,  it’s  enough  for  a  starting  point  as  we 
now  focus  attention  on  the  OFP  update  cycle. 


Section  Four 


THE  OFP  UPDATE  CYCLE 

Armed  with  your  newfound  knowledge  of  software  problems 
and  same  of  the  terminology  associated  with  the  update  cycle, 
let’s  look  at  the  update  cycle  itself.  The  cycle  is  a  dynamic 
and  ever  changing  process  that  overlaps  as  new  software  is  being 
fielded,  changed,  and  tested  simultaneously.  In  order  to  clarify 
this  description  of  the  update  cycle,  we’ll  use  an  example  based 
upon  the  author's  personal  involvement  with  the  cycle  as  a  TAF 
technical  focal  point.  The  example  will  show  how  one  particular 
change  evolved  from  an  idea  to  improve  the  operational 
effectiveness  of  the  AN/ARN-101  Digital  nodular  Avionics  System, 
better  known  among  the  Phantom  drivers  as  "Arnie",  through  its 
actual  implementation  in  the  latest  Arnie  DFP . 

AFR  000-14  divides  the  software  support  process  or  update 
cycle  into  five  functional  areas.  These  areas  include  request, 
process,  develop,  certify,  and  distribute  Csee  Figure  ID  C13:3B). 
Using  the  ARN-101  example,  we’ll  walk  through  the  process. 

The  cycle  begins  when  there  is  a  request  for  change  to  an 
OFP.  The  changes  originate  from  many  sources.  You,  as  the 
users,  may  require  a  software  change  to  accommodate  a  change  in 
operational  tactics,  mission,  or  addition  of  hardware  C7-.43).  A 
desire  to  increase  system  utility  accounts  for  many  requested 
changes.  The  maintainers  may  request  a  procedure  change  which 
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could  impact  the  QFP .  The  supporting  agency  produces  a  number  of 
□FP  changes  that  are  transparent  to  the  users  but  increase  the 
efficiency  of  the  operating  system,  Whatever  the  source,  a 
change  request  triggers  the  cycle  into  action. 

f — *  CHANGE  REQUEST  - - \ 


DISTRIBUTE 


PROCESS 


L  LI\  1  1  r  Y 

Ufc.Vc.LUr 

FIGURE  1.  THE  OFP  UPDATE  CYCLE. 

The  cycle’s  second  phase  begins  as  the  support  agencies 
process  changes.  User  OFP  change  requests  are  normally 
forwarded  to  the  TAF  technical  focal  point  at  either  USAFTAUIC  or 
USAFTFUJC .  The  technical  focal  point  reviews  proposals  for 
duplications  and  validates  them  for  TAF  wide  applicability.  At 
the  TAF  system  manager's  request,  the  technical  focal  point 
compiles,  prioritizes,  and  forwards  the  change  proposals  to  HQ 
TAC  C8 : . 

In  the  illustrative  example,  the  idea  originated  from  the 
TAF  technical  focal  point.  It  involved  changing  the  ARN-101  OFP 
to  facilitate  manually  changing  the  current  navigation  computer 
destination  point.  The  original  procedure  required  up  to  six 
keystrokes  to  change  the  destination  point  and  depending  on  the 
level  of  user’s  experience,  significant  heads-down  time  to 
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accomplish.  Being  able  to  accomplish  the  same  task,  using  a 
single  key  to  advance  or  backup  the  navigation  steer  point  stored 
in  the  navigation  computer  memory  would  decrease  heads-down  time 
and  effectively  improve  the  Arnie’s  operational  effectiveness 
CIS:  1-2).  CUIere  you  paying  attention  when  operational 
effectiveness  was  discussed  earlier?)  The  technical  focal  point 
forwarded  the  change  proposal  to  HQ  TAC  C1S:1). 

HQ  TAC  periodically  assembles  a  screening  panel  to  review 
proposed  changes.  The  users  then  prioritize  changes  based  on 
their  operational  impact.  Now  blessed  by  the  TAF,  HQ  TAC 
forwards  the  list  to  the  servicing*  ALC  providing  QFP  support 
CS: 3)  . 

In  the  example,  HQ  TAC  validated  the  suggestion  to  use 
single  keystrokes  to  advance  or  backup  the  navigation  point  and 
forwarded  it  to  the  supporting  ALC  Cin  this  case  Ogden  ALC)  for 
inclusion  in  the  next  block  cycle. 

At  the  ALC,  the  CS5P  (screening  panel)  combines  the  list  of 
recommendations  with  their  own  list  of  changes  (normally  changes 
which  increase  the  efficiency  of  software  execution  and  are 
virtually  transparent  to  the  operator) .  The  recommendations  are 
divided  into  functional  areas;  e.g.,  control  and  display,  weapons 
employment,  sensor  management,  navigation,  etc.  A  Material 
Improvement  Project  (HIP)  number  and  short  title  are  assigned  to 
each  recommended  change  for  accounting  purposes  (7:43).  Our 
example  change  proposal  became  HIP  50023  titled  "Aided  Manual  Fly 
to  Sequencing"  (17:3). 

Within  the  functional  area,  software  engineers  perform 
change  request  feasibility  studies  as  the  development  phase 


begins.  This  study  answers  the  basic  questions  about  the 
request.  Can  this  change  be  accomplished  via  a  software  change'7 
Will  it  impact  hardware?  What  resources  are  required  to  support 
this  change7  Can  the  change  be  accomplished  organically  Cin- 
house)  or  does  it  require  contractor  assistance7  C7:44;  15:1). 

If  the  change  can  be  made  using  organic  resources,  the 
engineer  prepares  an  estimate  of  the  resources  involved  in 
producing  the  change  to  include  manhours  required  to  produce  the 
change,  amount  of  memory  required,  impacts  on  other  OFP 
functional  areas,  and  associated  technical  order  impacts.  The 
feasibility  study  provides  the  information  required  to  authorize 
effective  changes  from  the  list  of  proposed  changes  C7:44). 

Aided  Manual  Fly  to  Sequencing,  our  example  request,  is 
determined  to  be  technically  feasible,  using  organic  resources, 
with  a  minimum  of  resources  required  to  effect  and  implement  this 
change  C 10 : 2-4 )  . 

The  CSSF  once  again  convenes  to  review  the  candidate  changes 
( 7 : 44 ) .  Based  an  feasibility  studies,  the  change  list  is 
finalized.  The  new  OFP  configuration  or  block  cycle  change,  is 
now  complete.  With  TAC  and  user  approval,  the  CSSP  closes 
the  block  to  further  changes  C7:44).  Further  changes  will  be 
added  to  the  list  for  the  next  software  block,  unless  HQ  TAC 
deems  necessary  to  change  the  candidate  list  to  incorporate  a 
mission  essential  software  modification  C7:44). 

The  software  engineers  now  write  software,  identify  affected 
documentation,  and  start  bench  tests.  Software  changes  are 
normally  produced  as  "patches"  to  the  existing  OFP.  Concurrently, 


changes  to  all  affected  technical  orders  and  documentation  are 
drafted.  Using  patches  and  marked-up  technical  orders,  the 
software  engineers  perform  preliminary  bench  tests  on  the 
Avionics  Integration  Support  Facility  (AISF)  test  bench  (7:81). 

The  changes  are  now  ready  for  certification.  Following 
satisfactory  bench  testing,  the  software  undergoes  flight  test. 
The  operational  command  must  certify  through  the  operational  test 
and  evaluation  process  before  it  is  released  C13-.7).  Upon 
satisfactory  completion  of  the  flight  checks,  the  software  is 
then  prepared  for  the  last  step  in  the  cycle,  distribution. 

The  SCCSB  maintains  release  authority  for  DFPs .  After 
flight  test  report  review  and  with  the  operational  command’s 
concurrence,  the  new  QFP  is  reproduced  and  released  to  the  field 
(7:44).  Released  in  the  form  of  a  TCTD,  you  should  see  the 
changes  to  your  flight  manuals  concurrent  with  the  software 
installation  in  your  aircraft  (7:68).  The  version  description 
document  (VDO)  is  also  released.  The  OFP  update  cycle  is 
complete . 

Our  sample  change  request,  Aided  ffanual  Fly  to  Sequencing, 
performed  satisfactorily  during  the  RF-4C  operational  test  and 
evaluation  (80:--).  The  ALC  identified  and  incorporated  changes 
to  affected  technical  orders  and  aircrew  flight  manuals.  Due  to 
a  limitation  in  the  available  F-4E  computer  memory,  the  CSSP 
dropped  the  patch  from  the  F-4E  software  to  accommodate  a  higher 
priority  change  to  the  weapons  list.  The  patch  was  retained  in 
the  RF-4C  software  (17:3;  16:1-13). 

Sounds  easy,  doesn’t  it7  Drop  a  request  in  the  mail  and 
magically  your  idea  is  processed,  developed,  certified,  and 
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delivered  to  you  in  the  next  change  to  the  software.  Although  it 
sounds  easy,  it  takes  a  great  deal  of  coordination  and 
extraordinary  management  techniques  to  orchestrate  a  change  to 
your  OFF.  As  we’ll  see  now,  the  potential  for  delays  within  the 
cycle  is  great. 
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Section  Five 


SYSTEM  BOTTLENECKS 

Any  complicated  process  is  vulnerable  to  breakdown.  Ue  have 
enough  experience  in  the  cycle  now  to  be  able  to  predict  where  the 
system  bottlenecks  occur  CEE: — ).  To  let  you  know  where  to  expect 
difficulties  in  working  with  the  OFF  update  cycle,  we’ll  look  at 
some  of  the  bottleneck  areas.  Major  bottleneck  areas  include 
reporting,  evaluating,  and  testing  of  the  proposed  enhancements. 

The  first  obstacle  in  the  update  cycle  is  the  reporting 
system.  The  official  deficiency  reporting  system  may  be  used  per 
TO  00-350-54,  USAF  Material  Oef iciencu  Reporting  and 
Investigating  System.  However,  aircrews  normally  report  desired 
enhancements  versus  true  system  deficiencies  and  therefore,  the 
format  and  report  requirements  specified  in  TO  00-35D-54  can  be 
confusing.  AFR  000-14  directs  that  command  and  local  procedures 
be  established  to  handle  software  change  requests.  If  you  have  a 
change  suggestion,  contact  the  responsible  technical  focal  point 
at  either  USAFTAWC  or  U5AFTFUC  for  the  latest  guidance.  As  a 
minimum,  the  technical  focal  point  will  need  the  information 
listed  in  AFR  800-14,  E5  September  1S86,  page  17,  paragraph  8-5b 
to  enter  your  suggestion  into  the  system. 

At  no  fault  to  the  operators,  problem  definition  also  is  a 
continual  problem  during  the  evaluation  phase.  The  more 
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thoroughly  and  clearly  a  problem  is  stated,  the  greater  chance 
there  is  in  quickly  finding  a  solution.  In  search  of  the 
solution,  software  engineers  often  must  "wargame"  the  situation 
and  try  to  second  guess  the  operator’s  intention. 

Suggesting  your  own  solution  may  help.  Remember,  most 
software  engineers  do  not  understand  the  "heat  of  battle"  aspect 
of  tactical  aviation.  Buying  time  is  a  valid  reason  for  changing 
the  software.  Hake  sure  you  clearly  express  and  support  the 
reason--  whatever  it  may  be--  for  the  request  in  your 
correspondence . 

One  important  aspect  of  the  OFP  update  cycle  that 
continually  plagues  the  supporting  agencies  is  requests  which 
involve  a  hardware  versus  a  pure  software  modification.  The  OFP 
update  cycle  can  only  affect  requests  for  software  changes  where 
the  support  ALC  uses  their  organic  C in-house)  resources  to 
produce  the  requested  change.  Knowingly  submitting  a  request 
which  involves  a  change  to  hardware  only  causes  bottlenecks  in 
the  system  and  needlessly  delays  the  update  cycle.  Hardware 
changes  follow  a  different  route.  If  in  doubt,  consult  your 
technical  focal  point  for  assistance. 

Sometimes  the  solution  to  a  software  change  request  may 
generate  a  corresponding  hardware  change.  In  these  cases,  the 
supporting  ALC  has  a  conduit  to  filter  the  request.  The  problem 
with  hardware  changes  is  funding--the  software  folks  do  not  have 
access  to  the  type  of  funds  required  to  support  pure  hardware 
changes . 

Once  an  OFP  enters  the  testing  phase,  the  potential  for 
delays  is  compounded  by  factors  unique  to  the  test  and  evaluation 


process.  Test  bed  aircraft  are  a  limited  resource,  with  high 
demands,  competing  for  scarce  instrumented  range  facilities. 

Test  criteria  demand  absolute  control  over  the  test  item  and  test 
variables.  However,  the  rigorous  test  process  is  necessary  to 
ensure  the  maximum  operational  effectiveness  and  suitability  for 
the  test  item.  Software  is  no  exception.  Don’t  be  discouraged 
if  your  change  is  "hung  up"  in  the  testing  process.  Take  heart. 
You’ve  made  it  through  the  major  portion  of  the  cycle.  Following 
successful  flight  test,  the  only  remaining  steps  in  the  cycle  are 
approval  and  distribution! 

Change  prioritization  can  be  a  potential  bottleneck  to  the 
system.  Often  users  fluctuate  the  emphasis  Ci.e.  change  their 
mind)  on  change  priorities  during  various  working  group  meetings. 
An  urgent  or  emergency  change  request  can  also  preempt  a  routine 
OFP  black  cycle  change.  Because  the  cycle  is  a  dynamic  and  ever 
changing  process,  there  can  be  more  than  one  cycle  in  various 
stages  of  completion  simultaneously.  If  the  priorities  change  in 
one  cycle,  the  domino  effect  can  seriously  impact  subsequent 
software  blocks.  At  the  user  level,  there  is  little  control  over 
the  priorities  assigned  different  change  suggestions.  The  bottom 
line  is  to  provide  solid  justification  for  your  submitted  change 
request  so  that  once  it  enters  the  cycle,  it  stays  in  line  with 
the  other  changes  and  does  not  get  "bumped." 


SUGGESTIONS  AND  RECOmENDAT I ONS 


The  OFP  update  cycle  provides  a  way  For  operational  aircrews 
to  improve  the  operation  of  their  weapon  systems  software.  But, 
the  system  is  not  without  its  problems  and  shortcomings.  How  can 
we  as  users  improve  the  cycle  and  make  it  more  responsive  to  the 
needs  of  the  users? 

User  education  is  a  good  place  to  start.  By  being  more 
aware  of  the  cycle,  what  it  involves,  and  how  it  works,  you  can 
participate  in  its  execution.  Perhaps  you’ve  never  heard  of  the 
cycle  before.  A  little  advertisement  of  the  cycle  and  its 
capabilities  is  bound  to  help. 

Currently,  there  is  no  user  education  or  awareness  provided 
for  the  system  users  at  the  very  basic  levels.  A  short  block  at 
the  schoolhouse  level  could  expose  everyone  to  the  existence  of 
the  OFP  update  cycle.  Later,  when  mare  experience  with  the 
system  is  obtained,  you’d  at  least  have  an  idea  of  how  to  upgrade 
your  OFP,  if  the  need  arises. 

Technical  focal  paints  may  be  of  some  assistance  to  increase 
user  awareness  of  the  OFP  update  cycle.  Since  TAC  has  assigned 
them  the  responsibility  for  OFP  management,  users  should  take 
advantage  of  their  expertise  when  considering  OFP  changes  or 
enhancements . 
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Unit  weapons  and  tactics  officers  may  already  have  or  can 
establish  OFP  working  groups  or  steering  committees  to  manage  QFP 


W! 


changes.  OFPs  could  be  added  to  the  agenda’s  of  major  TAF 


conferences  such  as  tactics  reviews  and  Major  Command  Manual  3-1 


rewrite  conferences.  Any  forum  where  aircrews  assemble  to 


discuss  weapons  system  management  is  an  excellent  opportunity  to 


discuss  and  prioritize  candidate  CFP  changes. 


Increased  unit  interface  between  the  user  organization  and 


the  software  support  agency  would  increase  the  efficiency  of  the 


process  CEE: — ).  Besides  the  unit  becoming  acquainted  with  the 


software  engineers  responsible  for  OFP  maintenance,  the  engineers 


would  benefit  by  learning  firsthand  why  certain  changes  are 


requested.  Remember  the  discussion  concerning  the  "heat  of 


battle"  aspect  of  tactical  aviation?  Communicating  heat  of 


battle  as  justification  for  an  OFP  enhancement  or  change  is 


difficult  to  accomplish  clearly  on  paper.  Face-to-face 


discussions  with  the  operators  could  help  the  engineers 


understand  same  change  requests 


A  word  of  warning  to  those  so  inspired  to  submit  an  OFP 


change  via  the  OFP  update  cycle:  the  wheels  of  progress  turn 


very  slowly.  It  could  be  as  long  as  three  years  before  you  see  a 


change  to  the  OFP  reflecting  a  particular  change  request  C^EO). 


Some  of  the  delay  is  by  design.  TAC  specifies  a  IE  month  OFP 


update  cycle  as  a  goal  (B:3).  This  is  to  keep  the  operators  from 


being  flooded  with  a  new  OFP  before  the  ink  is  dry  on  the  latest 


change.  The  support  agency  will  do  all  they  can  to  get  the 


changes  incorporated  into  the  OFP  as  quickly  as  possible. 


Section  Seven 


CONCLUSION 

This  OFP  overview  intended  to  make  you,  the  system  user, 
more  familiar  with  the  process  used  to  maintain  your  software's 
operational  effectiveness  and  suitability.  The  proliferation  of 
avionic  computer  systems  in  current  and  plans  for  future  aircraft 
have  spurned  a  mammoth  increase  in  software  supporting  embedded 
avionic  computer  systems  (2:60-77).  Mission  ready  aircrews  must 
be  familiar  with  the  processes  used  by  the  support  agencies  to 
optimize  weapon  systems  operational  effectiveness  and 
suitability.  But,  the  system  is  complex  and  traverses  major 
commands,  increasing  the  confusion  in  the  OFP  update  cycle. 
Therefore,  the  incentive  to  use  the  cycle  is  low. 

Having  been  on  bath  sides  of  the  fence,  as  a  mission  ready 
crewmember  and  as  a  technical  focal  point,  the  author  encourages 
your  participation  in  the  OFP  update  cycle.  While  it’s  true  the 
system  is  complex  and  has  limitations  and  bottlenecks,  it  could 
benefit  from  your  expertise  and  participation.  In  the  end, 
you’ll  be  better  prepared  to  face  your  adversary. 

The  system  works.  That  was  driven  home  while  viewing  Pave 
Tack  imagery  on  the  national  news  following  the  Libyan  raid. 

After  countless  meetings  concerning  software  controlling  Pave 
Tack  functions  and  data  displays,  there  was  a  great  sense  of 
pride  and  accomplishment  in  knowing  that  somehow  the  OFP  update 


process  contributed  to  Pave  Tack’s  combat  readiness  and 
ultimately,  to  the  raid’s  successful  result. 

Lieutenant  General  John  D.  Foss,  USA,  in  his  address 
"Leadership  American  Style”  emphasizes  the  importance  of  combat 
readiness.  General  Foss  says  one  thing  we  learned  "again"  from 
our  experiences  in  Grenada  was  "...you  go  to  war  the  way  you  are 
today--  not  the  way  you  want  to  be"  C21: — 5.  Is  your  OFP  ready 
to  go  to  war  today?  Or  is  there  something  you  could  do  to  make 
it  the  way  you  want  it  to  be?  Think  it  over  and  remember--  the 
□FP  update  cycle  needs  YOU! 
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